NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/7982

Internet Message Format | 1996-08-05 | 3.9 KB

Path: anvil.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: const char??
Date: 28 Feb 1996 10:45:18 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: anvil.ugrad.cs.ubc.ca

In article <[e-mail]>,
Lawrence Kirby  <[e-mail]> wrote:
 >In article <[e-mail]>
 >           [e-mail] "Kazimir Kylheku" writes:
 >
 >>        int * const x;
 >>
 >>The trick is to see the declaration of the type, and the further declarators of
 >>objects derived from the type as separate syntactic units. Immediate
 >>understanding is thereafter forthcoming. :)
 >
 >I'll take your word on that! :-)
 >
 >> >(There is a related issue that the function may also change *x by
 >> >using the lvalue *(char*)x. That, and similar tricks, are so bad
 >> >programming practices, that I won't even comment on them!)
 >>
 >>Hmm. Is that not a bit of an error, since the const modifier is being dropped
 >>in the cast? C allows you to only safely convert pointers of any type to void *
 >>and back to the same type. I will have to check references whether or not that
 >>"type" is so restrictive as to include any modifiers like const and volatile.
 >
 >6.3.4
 >
 >"It is guaranteed, however, that a pointer to an object of a given alignment
 > may be converted to a pointer to an object of the same alignment or less
 > strict alignment and back again; the result shall compare equal to original
 > pointer."
 >
 >6.1.2.5
 >
 >"The qualified or unqualified versions of a type are distinct types that
 > belong to the same type category and have the same representation and
 > alignment requirements."
 >
 >
 >So you can certainly cast between pointers to differently qualified versions
 >of the same type and back again. More simply I take:

Given that text, one can easily put ``two and two together'' from those
paragraphs.  Thanks for answering that one. I feel just a tad more
knowledgeable about C, yet again.

 >6.3.4
 >
 >"A pointer to an object or incomplete type may be converted to a pointer
 > to a different object type or a different incomplete type. The resulting
 > pointer might not be valid if it is improperly aligned for the type
 > pointed to."
 >
 >to mean that if the result *is* properly aligned (as in this case) then
 >the result is valid.

You probably can, if they intended to write ``if and only if'', which they
probably did intend.

 >>In any case, the cast does make it explicit that you are trying to voluntarily
 >>break the const. But in your function declaration you promised that you would
 >>not touch the object---why go through the bother of making that promise to the
 >>caller, when you intend to violate it?
 >
 >The cast doesn't necessarily violate the promise. Consider writing an
 >implementation of strchr() in C. The prototype is:
 >
 >char *strchr(const char *s, int c);
 >
 >It returns a pointer derived from s or NULL. Somewhere within this function
 >you are going to have to convert from const char * to char *. This function
 >does break the 'chain of constness' and if you pass it a const char * value
 >you should ensure that you assign the return value to a const char * variable.
 >To get around this strchr() would have had to return an offset rather than
 >a pointer.

Ah, I see. That makes sense, since strchr() has to manufacture a pointer
somewhere along the line, through which access to the string s could take
place. What if it is done immediately in the return statement of strchr()? As
in:

    return (char *) x;    /* x is (const char *)    */

That's one way to write the function which ensures that it never has in its
possession a pointer through which the string could be legally modified.
--